The diagnostics_channel subscriber is deferred via a microtask. This means node-redis >=5.12.0 operations performed immediately after Sentry.init() (in the same synchronous tick) can run before the subscriber is attached and will not be traced. Consider hooking this up from the OpenTelemetry init path (after the context manager is registered) or otherwise ensuring subscription happens synchronously before user code continues.

This file exposes _resetRedisDiagnosticChannelsForTesting(), but it only flips flags and does not unsubscribe any handlers already registered with diagnostics_channel. If tests call subscribeRedisDiagnosticChannels() again after a reset, you'll end up with duplicate subscribers (and duplicated spans). Consider keeping references to the subscriber objects (or channel instances) and calling channel.unsubscribe(...) during reset.

The JSDoc claims this is "Safe on every runtime" including Workers/Deno, but this is in @sentry/node (Node >=18) and relies on node:diagnostics_channel via @sentry/opentelemetry/tracing-channel. Consider tightening the wording to avoid implying support for runtimes where Node builtins (Buffer/diagnostics_channel) may not exist.

runResponseHook currently needs an unsafe cast for args to match the hook signature. Since CommandArgs already includes string | Buffer elements, this should be type-compatible without a cast (or you can type currentResponseHook as the redis response hook type). Removing the cast avoids masking real type mismatches.

This PR adds a new diagnostics_channel-based instrumentation path, but there are no unit tests covering span creation/end, error handling, or that the responseHook is invoked for command events. Since this package already has Redis tracing tests under packages/node/test/integrations/tracing/redis, it would be good to add a focused test suite for subscribeRedisDiagnosticChannels() using node:diagnostics_channel tracing channels.

Bug: batch and connect spans from the diagnostics_channel path have an inconsistent sentry.origin value because their asyncEnd handlers don't call runResponseHook to normalize it.
_{Severity: LOW}

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: packages/node/src/integrations/tracing/redis/redis-dc-subscriber.ts#L25

Potential issue: Spans created for Redis `batch` and `connect` operations via the
`diagnostics_channel` path are assigned a `sentry.origin` of
`'auto.db.redis.diagnostic-channel'`. Unlike command spans, which have their origin
overwritten to `'auto.db.otel.redis'` by the `cacheResponseHook`, the `asyncEnd`
handlers for `batch` and `connect` spans do not invoke this hook. This results in an
inconsistent `sentry.origin` attribute across different types of Redis spans originating
from the same integration, which can affect telemetry processing and filtering.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

Preload path permanently disables DC-based Redis instrumentation

High Severity

When instrumentRedis is called from the preload path (--import @sentry/node/preload), the deferred microtask fires before initOpenTelemetry() registers the SentryContextManager. The tracingChannel() helper fails to obtain the AsyncLocalStorage lookup (the OTel context manager is still the default noop), so channels are created without bindStore — meaning transformStart never runs and _sentrySpan is never set. The subscribed flag is then set to true, preventing re-subscription when Sentry.init() later calls instrumentRedis() a second time with the context manager properly available. Since the IITM patcher is now version-gated to <5.12.0, Redis >= 5.12.0 in the preload path gets no instrumentation at all.

 

^{Reviewed by Cursor Bugbot for commit f88ffb0. Configure here.}